Restore the CoreFoundation Swift overlay on non-Darwin - #5519

Thanks for the review. @compnerd

Why is the test limited to Linux?

The test prepends the freshly built Foundation library directory to LD_LIBRARY_PATH because the Swift toolchain also contains a libFoundation.so. Without that override, the generated RUNPATH resolves the toolchain library first, and the test executable fails at runtime because that library does not contain the new _CFObject symbols.

I limited the runnable test to Linux because that is the environment in which I could validate the dynamic-library setup. I do not currently have a local Windows environment to verify the corresponding test behavior.

If you have a convenient Windows setup, I would very much welcome a commit on this PR that adapts the runtime setup as needed and removes the Linux-only restriction for Windows.

Can you split up Hashable on _CFObject? That allows you to more easily see the implementation of the requirements.
Also, make Equatable explicit on the protocol as an explicit extension with the operator implementation.

Do you mean something like this?

// MARK: - _CFObject

public protocol _CFObject: AnyObject, Equatable, Hashable {}

// MARK: - _CFObject + Equatable

extension _CFObject {
    public static func == (lhs: Self, rhs: Self) -> Bool {
        CFEqual(lhs, rhs)
    }
}

// MARK: - _CFObject + Hashable

extension _CFObject {
    public var hashValue: Int {
        Int(bitPattern: CFHash(self))
    }

    public func hash(into hasher: inout Hasher) {
        hasher.combine(hashValue)
    }
}

Looks like the new test case I added here will not run by the CI since it is swiftpm based test. I'll create a swiftlang/swift multi-repo PR to update test entry and coordinate it.

Thanks for the review. @compnerd

Why is the test limited to Linux?

The test prepends the freshly built Foundation library directory to LD_LIBRARY_PATH because the Swift toolchain also contains a libFoundation.so. Without that override, the generated RUNPATH resolves the toolchain library first, and the test executable fails at runtime because that library does not contain the new _CFObject symbols.

Path is the lever to use on windows - there is no DT_RUNPATH equivalent. With the r3cent SxS work, the embedded manifest should also help bind the right version,

I limited the runnable test to Linux because that is the environment in which I could validate the dynamic-library setup. I do not currently have a local Windows environment to verify the corresponding test behavior.

If you have a convenient Windows setup, I would very much welcome a commit on this PR that adapts the runtime setup as needed and removes the Linux-only restriction for Windows.

My environment is currently setup for COM work, so it is difficult to switch.

Can you split up Hashable on _CFObject? That allows you to more easily see the implementation of the requirements.

Also, make Equatable explicit on the protocol as an explicit extension with the operator implementation.

Do you mean something like this?

// MARK: - _CFObject



public protocol _CFObject: AnyObject, Equatable, Hashable {}



// MARK: - _CFObject + Equatable



extension _CFObject {

    public static func == (lhs: Self, rhs: Self) -> Bool {

        CFEqual(lhs, rhs)

    }

}

You can also move the conformance here:

extension _CFObject: Equatable {
 ...
}

// MARK: - _CFObject + Hashable

extension _CFObject {

public var hashValue: Int {

    Int(bitPattern: CFHash(self))

}



public func hash(into hasher: inout Hasher) {

    hasher.combine(hashValue)

}

}

Likewise.

You can also move the conformance here:

extension _CFObject: Equatable {
  ...
}

No. Protocol is not allowed to do so IIRC. @compnerd

And I test it:

protocol A {}
extension A: Hashable { // ❌ Extension of protocol 'A' cannot have an inheritance clause
...
}

My environment is currently setup for COM work, so it is difficult to switch.

Got it. I'll try it without platform limitation first. If I can solve the CI issue that's fine. If windows platform is bumping some strange issues, I'll decide what to do then.

Clients importing CoreFoundation on non-Darwin platforms

Wait a minute - why is this a goal?

We specifically do not want people to use the C library on non-Darwin platforms. The Swift library is the API. The C library is an implementation detail (and one we are working towards removing by reimplementing its functionality in Swift).

We specifically do not want people to use the C library on non-Darwin platforms. The Swift library is the API. The C library is an implementation detail (and one we are working towards removing by reimplementing its functionality in Swift).

I completely agree with the long-term direction.

My point is simply that, today, the C library is still available on Linux and Android, and many existing packages depend on it.

We should certainly deprecate it gradually and encourage migration.

But as long as it's still part of the shipped implementation, fixing inconsistencies seems worthwhile. It improves compatibility for existing code without encouraging new dependencies on the C API. @parkera

@Kyle-Ye another option: follow Windows and later platforms and drop CF accessibility. The C interfaces are an implementation detail that are not meant to be available for users of Foundation.